home *** CD-ROM | disk | FTP | other *** search
/ Experimental BBS Explossion 3 / Experimental BBS Explossion III.iso / gus / sdkdigv8.zip / SDKV8N15.TXT < prev    next >
Text File  |  1994-01-17  |  3KB  |  79 lines
  1. Apparently-To: john.smith@gravis.com
  2.  
  3.  
  4. GUS Programmer's Digest     Mon, 17 Jan 94  4:00         Volume 8: Issue  15  
  5.  
  6. Today's Topics:
  7.                      Envelope Offsets not at zero
  8.                          Mod to 669 converter
  9.  
  10. Standard Info:
  11.     - Meta-info about the GUS can be found at the end of the Digest.
  12.     - Before you ask a question, please READ THE FAQ.
  13.  
  14. ----------------------------------------------------------------------
  15.  
  16. Date: Sun, 16 Jan 1994 05:59:43 -0600 (CST)
  17. From: Jason William Whiteman <jww9624@tamsun.tamu.edu>
  18. Subject: Re: Envelope Offsets not at zero
  19.  
  20. > fouling up.  An offset of 8 does mean 8, so don't set the ramp's
  21. > endpoint to 0.  8 is effectively silent anyway, and when it's 
  22. > reached, the volume can be set directly to 0 without causing a pop.
  23.  
  24.     The pseudo-code supplied should have made it clear that the 
  25. ramp would not go to zero. In the case of an offset of 8, the code
  26. would have said "ok, it's under the threshold of 10, so don't add the
  27. base_volume to the offset (base volume=volume when patch is started)."
  28. I am taking the envelope offset values to be an addative value (always
  29. with respect to the initial volume) unless the envelope offset is 
  30. below a threshold point.  Because you cannot add any positive value
  31. (unsigned char) to the initial volume and get silence (or near-silence),
  32. I implemented this conditional nature of looking at offsets.  However,
  33. if I think of the envelope offsets as a multiplying process, instead of
  34. and addative process, one formula could handle any offset value.  The
  35. point is: I just do not know.. A possible multiplying method: take the
  36. current volume and ramp to [ cur. vol * ( env_offset / 255 ) ].  
  37. This way, the next envelope's volume level would never be above the
  38. initial volume of the patch.  Perhaps this is correct?  
  39.     I appreciate the response.  The wording tended to imply a
  40. geometric nature to envelope values.
  41.  
  42. > Phat.
  43.  
  44. Jason Whiteman
  45.  
  46. ------------------------------
  47.  
  48. Date: Mon, 17 Jan 1994 10:36:46 +1030 (CST)
  49. From: Gavin <SCARMAN@hfrd.dsto.gov.au>
  50. Subject: Re: Mod to 669 converter
  51.  
  52. >Does anyone have/seen a .MOD to .669 converter?
  53. Yes but it does a poor job with tempo changes. I don't have a 669 editor so I've 
  54. never seen whether these can be fixed. If you want it I can send it uuencoded if 
  55. you'll promise to upload it to epas, I got it from a BBS.
  56.  
  57. ------------------------------
  58.  
  59. End of GUS Programmer's Digest V8 #15
  60. *************************************
  61.  
  62. To post to tomorrow's digest:                    <gus-sdk@dsd.es.com>
  63. To (un)subscribe or get help:            <gus-sdk-request@dsd.es.com>
  64. To contact a human (last resort):          <gus-sdk-owner@dsd.es.com>
  65.  
  66. FTP sites:           archive.epas.utoronto.ca              /pub/pc/ultrasound
  67.                      wuarchive.wustl.edu            /systems/ibmpc/ultrasound
  68.                      archive.orst.edu                    /pub/packages/gravis
  69.                      theoris.rz.uni-konstanz.de                /pub/sound/gus
  70.                      nctuccca.edu.tw                           /PC/ultrasound
  71. FTP mail server:     mail-server@nike.rz.uni-konstanz.de
  72.  
  73. Hints:
  74.       - Get the FAQ from the FTP sites or the request server.
  75.       - Mail to <gus-sdk-request@dsd.es.com> for info about other GUS
  76.     related mailing lists (general use, musician's, etc.).
  77.  
  78.  
  79.